The last time I wrote about this thing, I called it a diagnostic laboratory living in the browser. That was true then, and the label already felt slightly too small - by the time you finish reading this, it'll feel wildly too small. Somewhere between v1.6.0 and today's v2.0.0 release, Target Data stopped being "a really good DevTools replacement" and turned into something closer to a self-contained research platform: a tool you point at a web application and use to actually understand it, probe it, and reason about it, without ever leaving the tab you're already in.
Six phases happened in between. Recursive discovery. Smarter status classification. Method override and parameter pollution testing. A workflow profiler that turns a burst of network noise into a readable sequence. A polling analyzer that catches an app quietly hammering an endpoint in the background. A DOM diffing engine borrowed from the snapshot comparer and pointed at live interactions. A macro recorder that turns your own clicks into a repeatable script. Storage alerts that ping you the moment something changes behind your back. A read-only proxy that lets you poke at a page's internals with an actual safety net under you. A keep-alive for WebSockets that don't want to stay open. And, closing it out, a mocking proxy that lets you rewrite the network entirely - test your frontend against a response the backend hasn't shipped yet, or that it never will.
None of this replaced what was already there. It all sits on top of the same foundation: the traffic capture, the endpoint catalog, the fingerprinting, the misconfig audit, the JS console, the replay and sweep tooling, the recorder, the tracer, the token inspector, the snapshots. If you read the original walkthrough, that part of the tool works exactly like it did - it just has a lot more company now.
This is a tour of everything that's new, told the way I'd actually explain it to someone at a desk next to me, not the way a changelog would.
For anyone coming in cold: Target Data lives behind a small flask icon in the corner of the screen. Tap it, and a panel opens with a dark or light theme, drag-to-reposition, and a set of grouped tabs covering everything from DOM inspection to network reconnaissance to active security testing. It captures every fetch, XHR, and form submission the page makes, builds a live catalog of every endpoint it's seen, and keeps that catalog around across reloads. It fingerprints the tech stack running underneath the page, checks for the kind of misconfigurations that show up in a real security review (missing headers, loose CORS, open GraphQL introspection), and rolls all of that - plus everything new below - into a single scored Findings list you can scan at a glance.
If any of that is unfamiliar, the earlier walkthrough covers it in full. What follows assumes you already know your way around the panel and just want to know what's changed.
The brute-force and parameter tooling was already solid at 1.6.0. What it didn't have was judgment - it would try candidate paths and report status codes, and you did the interpreting yourself. That's changed.
Path discovery can now chase its own tail, on purpose. Flip on Recursive Mode before a run, and every directory-shaped hit it turns up - anything ending in a slash that comes back 200 or 403 - automatically gets queued for a follow-up pass using the same wordlist, scoped to that new path. It goes three levels deep and then stops, which is enough to map out a nested API surface without accidentally asking it to enumerate the entire internet. You get a running readout of which level it's on and how much is still queued, and results from every level accumulate in the same list instead of overwriting each other, so a long recursive run doesn't erase its own history as it goes. A manual override is still there too - any single directory hit can be sent off on its own dedicated brute-force pass without touching the automatic mode at all.
Generic wordlists are a decent starting point and a mediocre ending point. Target Data can now read the actual page you're standing on - its element IDs, its class names, its data attributes, the string literals sitting in inline scripts - and turn what it finds into a set of candidate paths shaped like /token and /api/token. It filters out the obvious noise (styling classes, common utility words, anything that's clearly not a slug) and caps itself at a reasonable number of candidates so it doesn't run away with itself. The generated list merges into whatever wordlist you already have rather than replacing it, so it's additive by default.
A lot of applications don't actually return 404 for things that don't exist. They return 200 with a "not found" message in the body, or they quietly redirect to a login page and call it a day. Treating those as hits used to mean your results list filled up with false positives. Now every response gets classified - hit, protected, not-found, or error - based on both the status code and a scan of the body for the telltale phrases that mean "this isn't really here" or "you're not allowed to see this." Results are color-coded accordingly, the hide-filter actually hides soft-404s along with the literal ones, and the classification feeds directly into what counts as a real hit for every downstream feature - Findings, the traffic catalog, everything.
Some backends enforce access control at the routing layer and just... don't check the method as carefully as they check the path. Method Override Detection sends a baseline request and then tries the same real HTTP verb dressed up as something else, two different ways: an X-HTTP-Method-Override header, and a _method query parameter (the old Rails convention). If a baseline that came back blocked or missing suddenly succeeds once the override is applied, that's flagged immediately as a likely bypass. There's an opt-in, heavily-warned mode to also fire the literal method for real, but it's off by default - the header and parameter checks alone usually tell you what you need to know without actually performing the action.
Parameter pollution is one of those bugs that's invisible until you go looking for it specifically. Parameter Handling Analysis picks a set of parameter names - a curated default list, easily swapped for your own - and for each one sends three variants: a single clean value, that same value duplicated, and two conflicting values. If the conflicting-values request behaves differently from baseline while the duplicated-same-value request doesn't, that's a strong signal the backend is resolving duplicate parameters in a way that's worth understanding - first-wins, last-wins, or something messier. Weaker signals (where even the simple duplicate diverges) get flagged too, just with an honest note that it might just mean the endpoint doesn't like repeats in general.
Both of these new discovery tools can pull their targets straight from what you've already captured - a "Send to" button sits on individual traffic entries and endpoint catalog rows, plus a bulk option that respects whatever filter you've got applied in the catalog view. No more retyping URLs you've already seen go by.
This is the part of the update that surprised me most, because it's not about finding vulnerabilities - it's about understanding an application's real-world behavior, which turns out to be just as hard to get right by eyeballing DevTools.
Every meaningful user action in a modern app - saving a form, checking out, loading a dashboard - triggers more than one request, usually in a specific order, sometimes overlapping. Trying to reconstruct that sequence by scrubbing through the Network tab after the fact is tedious and error-prone. The Workflow Profiler flips the process around: you arm a capture window (anywhere from three seconds to a full three minutes now), go trigger the action on the page, and it passively pulls in everything Traffic already saw during that window.
What comes back is a proper sequence view: each request with its offset from the start, its duration, and a flag for whether it overlapped with the one before it or waited politely for it to finish. There's also a "minimum request set" summary - the count of unique method-and-URL combinations versus the total number of calls made, with any exact repeats called out by name. That last part is quietly useful for performance work; it's the fastest way I've found to spot an action that's calling the same endpoint three times when it only needed to once.
Some pages poll. A lot of them poll more aggressively than anyone intended, especially once a feature that used to be occasional gets left running in the background after a refactor. Application Polling Analysis works the same way as the workflow profiler - arm a window, let the page sit and do whatever it does - except instead of building a sequence, it groups everything by endpoint (ignoring query string noise so the same call with a different cache-busting parameter still counts as one endpoint) and computes a requests-per-second rate for each.
Anything that crosses a threshold you set gets called out as chatty. The threshold is genuinely yours to configure, and results respect it live - lower it after a capture and previously-quiet endpoints get reclassified without needing to run the capture again. Every capture from both of these tools sticks around in a little history list with an optional label, so you can build up a small library of "checkout flow," "idle dashboard," "search-as-you-type" and flip between them.
Here's a genuinely fiddly kind of bug to chase down by hand: something visually changes when you click a button, and you need to know exactly what, structurally, actually happened in the DOM - not "the cart count went up," but which elements were added, which were removed, and which just had an attribute or a bit of text quietly swapped out underneath them.
This tool borrows the same diffing engine that already powers the Snapshot comparison feature and points it at a live element subtree instead of a storage dump. Pick a target - or don't, and it'll watch the whole page - arm it against an event (click, input, change, submit, or something custom), and it captures the tree before the event fires, waits a configurable settle delay for anything async to catch up, and captures again after. What comes back is a categorized list: added, removed, modified, each described in plain terms like body > div.cart > span rather than a wall of raw diff paths. There's also a manual two-button mode for changes that don't have a clean event trigger at all - useful for anything that updates on a timer or after a network response lands with no user interaction involved.
The Investigation Recorder has always logged what happens on a page while it's active - clicks, inputs, console output, mutations, the works. What it never did was give you something you could hand back to the page and say "do this again." The Session Macro Recorder does exactly that, and deliberately does less than the Investigation Recorder in order to do it well: it watches your clicks, your inputs, your form changes, and your submits, and nothing else. No cookies, no tokens, no storage, no session state - just the interactions themselves, captured as selectors and values with real timing between them.
Save a macro, give it a label, and play it back at whatever speed you like - slower to watch it step through, faster to just get it done. Each playback logs whether every step actually found its target and whether it succeeded, so a macro that breaks because the page changed underneath it tells you exactly where it broke instead of failing silently. This is the fastest way I've found to hand a bug reproduction to someone else, or to just save myself from re-typing the same test data into the same three fields for the fifth time in an hour.
The Storage Watcher already polled localStorage, sessionStorage, and cookies for changes and logged what it found - but you had to be looking at the tab to notice. Now there's an "alert on change" option that fires a flash notification (with an optional beep) the moment a watched value actually changes, so you can be three tabs away doing something else and still catch the exact instant a token rotates or a flag flips.
The JS Console has always been the most powerful and most dangerous tab in the panel - it runs directly against the live page, full stop, no undo. Phase 11 didn't change that fundamental trade-off, but it did add two ways to work more carefully when carefulness is what the moment calls for.
"Safe Read-Only Mode" isn't a warning label - it's an actual proxy wrapped around window, document, localStorage, and sessionStorage before your code ever touches them. Reads pass straight through untouched. Writes, deletions, and the obvious storage-mutating methods - setItem, removeItem, clear - get intercepted, logged, and silently no-op'd instead of actually happening. Every blocked attempt shows up right under your result: the path, the value it tried to write, right there for review.
It's honest about its limits, which matters more than it sounds like it should. A function call can still have side effects inside itself that this can't see - fetch() making a real request, or a page method that mutates something internally rather than through a property you touched directly. This is a guard rail against the accidental direct write, not a hermetically sealed sandbox, and it says so plainly in the tool rather than overselling what a JS proxy can actually guarantee.
The second toggle in that same tab catches uncaught errors and unhandled promise rejections happening anywhere on the page - not just in code you personally ran - and logs them into a small panel right there in the console tab. It's a small thing, but it's saved me from the specific frustration of a page silently breaking mid-investigation and only finding out ten minutes later when nothing made sense anymore.
WebSocket connections used for real-time state have a habit of timing out during a long, slow, thoughtful debugging session - which is exactly the kind of session this tool is built for. Pick an open connection, set an interval and whatever ping message the backend expects, and it'll keep sending that message on schedule until you turn it off or the connection closes on its own. Nothing about it captures or replays a sequence - it's a heartbeat, not a recorder - and the pings show up in the ordinary message log like anything else sent through that connection, so you can always confirm it's actually firing.
The last major piece, and the one that finally earns the 2.0 label, is the Response Mocking Proxy.
It intercepts fetch() calls - not XHR, not WebSocket traffic, just fetch, which covers the overwhelming majority of modern API calls - and for anything matching a rule you've defined, returns a response you wrote instead of whatever the real backend would have said. Match by URL (a substring, an exact match, or a full regex) and method, then define the status code, headers, body, and an optional artificial delay to simulate a slow backend. It's the difference between waiting for an API endpoint to exist and just deciding it already does, for testing purposes: build the frontend against the shape of a response the backend hasn't shipped yet, or reproduce an error state, an empty state, or a weird edge-case payload on demand, exactly when you need to see how the page handles it.
Everything about it is built to stay visible rather than sneaky. A rule you toggle off doesn't apply. Turning mocking on at all requires an explicit confirmation, because it affects every fetch call on every tab of the page until you turn it back off. And while it's active, there's no missing it - a red dot sits on the launcher icon whether the panel is open or not, and a "MOCKING ON" badge sits right in the panel's own title bar. Every intercepted request gets logged in a dedicated view and also recorded into the ordinary Traffic tab, clearly labeled with which rule caught it, so a mocked response never quietly gets mistaken for a real one three tabs later.
None of the above lives in isolation. The Findings panel - the consolidated, scored list that already rolled up tech fingerprinting, misconfigurations, GraphQL introspection, and flagged parameter sweeps - now also pulls in flagged method override results, flagged parameter handling inconsistencies, chatty polling endpoints, and redundant repeated calls from workflow captures. Each source is scored on its own terms - a confirmed method-override bypass sits near the top, a mildly chatty endpoint sits lower as an efficiency note rather than a security concern - but they all show up in the same place, sorted the same way, each one tappable straight through to wherever it was actually found.
And everything new writes cleanly into Export and the AI Briefing, the same as everything old did. Workflow captures, polling captures, DOM deltas, macros, mock rules - it's all there in the CSV and the plain-language summary, category by category, exactly like the tool has always done it. Nothing new got left as a second-class citizen just because it shipped later.
Going back to the metaphor from the first walkthrough: this stopped being a diagnostic laboratory somewhere around the polling analyzer and the macro recorder, and became something closer to a proper research bench - one where you can not just look at what a page is doing, but reshape what it does, safely, and understand the difference before and after. The foundation from 1.6.0 is all still there, doing exactly what it always did. It's just got a lot more built on top of it now, and all of it actually talks to the rest.
That's 2.0.0.